Skip to content

Make Result class containt Java's BufferedImage field#30

Closed
IceMajor2 wants to merge 5 commits intoimagekit-developer:masterfrom
IceMajor2:new-feature
Closed

Make Result class containt Java's BufferedImage field#30
IceMajor2 wants to merge 5 commits intoimagekit-developer:masterfrom
IceMajor2:new-feature

Conversation

@IceMajor2
Copy link
Copy Markdown

Hi. I've been recently using ImageKit library for Java, mainly for uploading images programmatically. Throughout my not-so-long experimenting with it, I've found that it may perhaps be helpful to have a ready-to-use Java AWT's image object after having sent an image to external hosting (ImageKit :) ).

I've taken a stab at trying to accomplish so.

GOAL: Result class contains BufferedImage field

Problem: Not every file needs to be an image and not every image will neccessarily be read by ImageIO.read.
In FileCreateRequest class, I've added isReadableImage field, which is set whenever any of the 3 constructors is called.
In Utils, I've written isReadableImage methods. They take a reference to image source in forms of base64-encoded string, simple String path or instance of URL class. I've also written tests for them which pass (they test for both files that are images, and for simple .txt file). Note: the isReadableImage method will not return true for every image as ImageIO.read does not support every format. For example, in order to read .webp images this way, we would additionally need plugins, which I've not included.

I've also thought of creating another Result class, especially for images, but I realised it may be too much at once ;)

This is my first contribution to open source project, I'd love some feedback. I'm open to work on this as well as on other issues.

@imagekitio
Copy link
Copy Markdown
Contributor

Thank you for the contribution! However, we've decided not to merge this PR for the following reasons:

  1. Separation of concerns - The SDK's responsibility is API communication, not image processing. Mixing these concerns adds unnecessary complexity.

  2. Memory overhead - Automatically loading BufferedImage for every upload would consume significant memory, even when users don't need it.

  3. Limited format support - ImageIO doesn't support all image formats (e.g., WebP), which would create inconsistent behavior.

  4. User flexibility - The current design returns the url field, allowing users to download and process images using their preferred libraries and formats:

val response = client.files().upload(params)
val bufferedImage = ImageIO.read(URL(response.url()))

The SDK intentionally stays lean and focused. Users needing additional image processing can easily implement it on their side.

@imagekitio imagekitio closed this Apr 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants